The provision of IP multicast services has become increasingly important, especially in view of recent advances in the distribution of television signals over IP networks.
The group membership reporting functions and messages required for the provision of IP multicast services is governed by the Internet Group Membership Protocol (IGMP) standard. A new version of the standard (Version 3) described in RFC 3376 is currently being implemented. IGMPv3 can be used to provide IP television (IPTV) enhanced services.
FIG. 1 is a schematic diagram of an exemplary distribution network for providing IPTV service to service subscribers. A video head end receiver 10 receives a plurality of television signals associated with different television channels 12-16. A copy of each television signal is fed to a broadband service router (BSR) 18 using, for example, a statically configured link. The BSR 18 in turn sends one copy of each signal to a Broadband Service Aggregator (BSA) 20. Copies of each channel that is being consumed by a subscriber served by an access node, such as a digital subscriber line access multiplexer (DSLAM) 22a-22c, as indicated by IGMPv3 group membership messages (joins) sent from the DSLAMs 22a-22c to the BSA 20. Alternatively, consumed channels may be delivered directly to a DSLAM 22d. The DSLAMs 22a-22d receive IMGP group membership messages (joins) from subscriber premises residential gateways (RGs) 24a-24g or directly via a modem with a bridging function (not shown) from subscriber premises set top boxes (STBs) 26d and 26f. As will be understood by those skilled in the art, only a few residential gateways 24 and a few set top boxes 26 are shown for clarity.
The STBs 26 act as IGMP hosts. When a RG 24a-24g operates in routed mode, it supports an IGMP proxy function that acts as an IGMP router towards the STBs 26a-26c and 26e, and as an IGMP host towards the DSLAMs 22a, 22c and 22d. Each television signal (channel) is associated with a multicast group distributed on demand by the DSLAMs 22 to the RGs 24a-24g and/or the STBs 26d, 26f. The IGMP join messages indicate the IP multicast group(s) that the RGs 24 and/or the STBs 26d, 26f wish to join in response to commands input by IPTV viewers or automated STB functions.
As part of the evolution of IPTV services, the number of multicast streams supported by distribution equipment must be increased throughout the network. This is due to an increase in the number of channels being offered in IPTV networks, and by an increase in an average number of streams being consumed per STB, particularly since the introduction of IPTV mosaic features.
Not only does the increased number of multicast streams result in higher “zapping” (channel changing) concurrency, but also in a higher maintenance message load to support IGMP membership messaging. Two types of management messages are of particular importance to IGMP membership messaging, the Membership Query and the Membership Report.
FIG. 2 is a schematic diagram of the format of an IGMPv3 Membership Query message. Membership Queries are sent by IP multicast routers to query the multicast reception state of neighboring interfaces. The Type field 102 identifies the message as a membership query message. The Max Resp Code field 104 specifies a maximum time allowed before a membership report is to be sent by a receiver. The actual time allowed, called the Max Resp Time, is represented in units of 1/10 second and is derived from the Max Resp Code as follows: If Max Resp Code<128, Max Resp Time=Max Resp Code; If Max Resp Code>=128, Max Resp Code represents a floating-point value as follows: Max Resp Time=(mant|0×10)<<(exp+3).
A Checksum 106 is a 16-bit one's complement of the one's complement sum of the whole IGMP message (the entire IP payload). A Group Address field 108 is set to zero when sending a General Membership Query. A Resv (reserved) field 110 is set to zero on transmission, and ignored on reception. An “S” Flag (Suppress Router-Side Processing) field 111, if set to ‘1’ indicates to any receiving multicast routers that they are to suppress the normal timer updates they perform upon hearing a Query. If non-zero, a QRV field 112 contains the [Robustness Variable] value used by the querier, i.e., the sender of the Query. A Querier's Query Interval Code (QQIC) field 114 specifies a [Query Interval] used by the querier. A Number of Sources (N) field 116 specifies how many source addresses are present in the Query. This number is zero in a General Query or a Group-Specific Query, and non-zero in a Group-and-Source-Specific Query. The Source Address fields 118 are a vector of n IP unicast addresses, where n is a value in the Number of Sources (N) field 116.
While it will be appreciated by those skilled in the art that some management messaging enhancements are available in IGMPv3, a strict interpretation of the protocol can lead to increased peak message processing requirements, particularly within access nodes such as DSLAMs. For example, as explained above the query response interval coding (Max Resp Code 104) now allows for a larger range of values than permitted in IGMPv2 (maximum of 25 seconds). For proper operation of IGMPv3 membership messaging, the query response interval should be less than the query interval. The new Max Resp Code 104 supports values up to, and even greater than, the 125 second default query interval. Thus, a lengthened query response interval (up to the query interval) can be used to help distribute membership report message processing loads.
However, IGMPv3 recommends that membership report messages include multiple current-state Group Records up to maximum message size. This IGMPv3 record aggregation feature is helpful in expediting the join and leave processing using unsolicited membership reports when an event affects multiple groups simultaneously, eg. grid-guide scrolling. For General Membership Queries, however, while this aggregated IGMPv3 group solicited report reduces overall message load compared to IGMPv2, it can result in non-deterministic behavior resulting in bursty and lengthy message processing conditions when a large number of current-state Group Records are included in a single solicited IGMPv3 membership report.
RFC 3376 clearly states that a system must maintain a timer per interface for scheduling responses to a general membership query (GMQ). The RFC also indicates that this timer should assume a random value between 0 and a maximum response time derived from the Max Resp Code 104. RFC 3376 also specifies that multiple state records be packed into report messages to the extent possible (MTU limits restrict the maximum number of groups that may be reported in a single message). Therefore, upon expiry of the timer, a membership report message is sent that contains a current state record for each multicast address for which the host has a reception state (each multicast group that the host believes it has joined).
There is however a note in Section 5.2 of RFC 3376 that suggests that reporting on a large number of groups may result in a burst of packets if a larger number of groups are to be reported than will fit in a single report message. Specifically, RFC 3376 suggests that rather than using a single timer in such instances, report messages be spread over the interval 0 to maximum response time. However, RFC 3376 fails to provide an algorithm for accomplishing the message spreading.
There therefore remains a need for a method and apparatus for distributing the General Query Message processing load required for IGMPv3 membership maintenance.